IBIS Macromodel Task Group Meeting date: 29 September 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC * David Banas Marc Kowalski Ericsson: Anders Ekholm IBM Steve Parker Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz * Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Arpad noted that he had removed two BIRDs from the "Pending BIRDs" list in the ATM Agenda. BIRD 157, Parameterize [Driver Schedule], had been voted down in the Open Forum meeting. BIRD 178, Specifying Buffer Directionality for AMI, had been approved by the Open Forum and is now part of the released IBIS v6.1 specification. - Arpad noted that we may need to cancel the ATM meeting the last week in October because of people traveling for the IBIS Summit held at EPEPS. He said this would be finalized during upcoming meetings. - Ambrish mentioned that work commitments had kept him from making progress on the Back-channel proposal (BIRD 147). -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad to work on the next revision of the Info, Out, InOut BIRD draft based on the language changes proposed during last week's discussion. - Done (see discussion below). ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Todd: Motion to approve the minutes. - Arpad: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Item #6: Info, Out, InOut BIRD draft. - Arpad: [sharing some new language proposals he had emailed to the reflector] - Today I would like to answer the following question: - What type of special parameters should be listed in this new Reserved parameter? Should we list only those parameters without which the model would be completely broken, not able to perform even the basic IBIS-AMI functionalities, or should we also list those parameters that are needed for "above and beyond" normal features? - I believe Walter's preference was to list both types, even new features. - John: Could we start with this proposed definition? [following] - Any Model Specific parameter that requires the tool to do anything other than just get the user's input (provide a value) or display it to the user should be listed in this new keyword. - Mike L: That sounds like it lines up fairly well with Walter's proposal. - Radek: I think we've agreed to that several times. - John's way of phrasing it is good. - Arpad: I want to discuss the word "requires". - John: Requires in order for the model to function as the model maker intended. - Bob R: If the model maker wants the features used, the parameter(s) should be listed. - Walter: Requires is not a good word here. - Any Model Specific parameter for which the model maker expects the EDA tool to do something other than allow the user to select a value or display the value should be listed. - We've all said the same thing several ways. - I think we are all in agreement. - We don't need any requirements on what bad things will happen, etc. - Arpad: Okay, this decision has been reached. - Given this decision, the follow on question is: - Would it be useful to have an indicator for each of the special parameters to indicate whether it is part of a new feature or required to get proper results out of standard simulation flows? - It sounds like it might be useful to have a "severity" indicator. - Walter: The information would be useful. - It should be given to the user as the description field of the parameter. - The model maker should describe what the parameters do. - We should leave this to the model maker. - Radek: I think the original agreement was not to complicate things with this indicator parameter. - However, now that the new Reserved parameter has Format Table, it would be easy to add another column. - It might be easy to add another bit of useful information. - Arpad: I agree. - A second column would be parseable, as opposed to description field text. - The tool could then decide, when it doesnt recognize the name of a special parameter, whether it can perform the basic AMI simulations or not based on the severity indicator. - Discussion: Do we need a severity indicator for non-standard parameters? Participants understood the value of the information Arpad's proposal was attempting to provide, but there was disagreement about whether the proposal would work in practice. Bob R. agreed with Walter's position that it was an unnecessary complication, and suggested that there would always be a grey area between any two defined severity levels. Todd stated that he was worried that we were already asking model makers to list their non-standard parameters, and asking them to now flag them as the "critical" type might be a bridge too far. Tstone models were again introduced as an example. Todd suggested that tstone might not be flagged as critical, since the workaround was well documented and easy. Radek countered that the workaround might not be trivial depending on how the IBIS Model had been formulated. Bob M. noted that as a model maker who had released tstone models he would list it as critical to ensure the users were alerted. John, Bob M., and others noted that if we were debating the way to characterize tstone models then it would be hard to expect model makers to uniformly characterize their parameters. Arpad felt the issue could be addressed by properly defining the criteria for the severity levels in the spec. He also suggested we might use a term other than severity if that sounded too harsh. Ambrish reiterated that this entire BIRD was all voluntary on the model makers' part, and adding further indicator fields would be an unnecessary complication. Todd suggested that we have a vote to see where people stood on the topic. Walter suggested that each person vote, as opposed to each company, since this was a non-binding vote just to gauge the opinion of participants. Arpad and Mike L. noted that the vote was not official, and Arpad phrased the vote, "Should we add a severity parameter for the non-standard parameters?" Results of Participant Vote: Dan Dvorscak No Curtis Clark No Bob Miller No Ambrish Varma No David Banas No Michael Mirmak Abstain Radek Biernacki Abstain John Angulo No Arpad Muranyi Yes Randy Wolff Abstain Walter Katz No Todd Westerhoff No Mike LaBonte No Bob Ross No Totals: No - 10 Yes - 1 Abstain - 3 - Arpad: The feelings of the group seem pretty clear. - Arpad: I would now like to review the proposed language. - Ambrish: Will this have an impact on the parser? - Bob R: The parser will be cross referencing names from the new parameter to make sure they exist in the Model Specific parameters. - Discussion: Parser handling of the new parameter. Ambrish and Arpad suggested that the parser should issue a warning if the new parameter appeared at all, and an error if the new parameter contained the name of a parameter that did not exist in the Model Specific section. Bob R. suggested that the parser should issue a note and warning respectively in those two cases. Bob R. asked that any parser handling requirements be documented in the "Background information:" section of the BIRD and not in the text of the actual BIRD (spec). Mike LaBonte agreed with this, and suggested that these topics might be handled in the IBIS Quality Group. - Arpad: Thank you all for joining. ------------- Next meeting: 6 October 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives